REMARKS 

Claims 1, 2, 5 and 6 are pending in the present application. Claims 1 and 2 have 
been amended herein. No new matter has been added. Applicant requests 
reconsideration of the amendment and allowance of the application in view of the 
following remarks. 

As an initial note, the step 2) in former claim 1 is corrected by deleting "checking 
a version number" to make claim 1 clear and in conformity with the specification because 
"checking a version number" is not always necessary according to the A) to F) as well as 
Figure 4 and steps 401 to 414 in the specification. This amendment overcomes the defect 
that "checking a version number" also contradicts steps 2D) and 2E) and does not raise 
new issues. The amendments to the claims contained herein do not extend beyond the 
originally disclosed application. The Examiner is respectfully requested to reconsider and 
withdraw the rejections in view of the amendments and remarks contained herein. 

Claims 1, 2, 5 and 6 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable over 3GPP Release 1999 - TS 29.060 v3.7.0 (2000-12) by 3GPP Release 
1999 Organizational Partners (hereinafter "3GPP Release 1999") in view of 3GPP - TS 
09.60 V6.10.1 (Release 1997), (hereinafter "E3GPP RELEASE 1997"). Applicant 
respectfully traverses this rejection. 

Firstly, the amended claim 1 provides a method for processing Create Packet Data 
(PDP) Context Request can solve the potential trouble of incompatibility between two 
versions of GTPvO and GTPvl. In contrast hereto, 3GPP 1999 only describes the 
optimized and updated version of GTPvO (i.e. GTPvl) and 3GPP 1997 only describes 
definitions of GTPvO. Each of 3GPP 1997 and 3GPP 1999 is complete and functional in 
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itself, so there would be no reason to use parts from or add or substitute parts to any 
reference. Neither of the 3GPP 1999 and the 3GPP 1997 teaches or suggests the method 
which can solve the potential trouble of incompatibility between two versions of GTPvO 
and GTPvl . Currently, there is still no prior art that points out the incompatibility 
between two versions of GTPvO and GTPvl or provides a solution to solve the 
incompatibility problems . Since the problem solved by the invention is never even 
recognized before, the recognition of an unrecognized problem militates in favor of 
patentability. 

Secondly, it can be easily seen that 3GPP 1997 defines one cause value of "No 
resources available" to indicate the cause of lack of resources. While, 3GPP 1999, defines 
three cause values "No resources available" , "All dynamic PDP addresses are occupied" 
and "No memory is available" to indicate the same type of cause that the cause of lack of 
resources with 3GPP 1997. However, the GTPvl defined in the 3GPP 1999 does not 
disclose how to use those three cause values or how to implement the communication 
between the GTPvO and the GTPvl. Therefore, the combination of 3GPP 1999 and 
3GPP 1997 suggested requires a series of separate, awkward combinative steps that are 
too involved to be considered obvious. Since the same case value of "No resources 
available" in both 3GPP 1997 (GTPvO) and 3GPP 1999 (GTPvl) is available to indicate 
the cause of lack of resources, a person skilled in the art would use such cause value 
obviously. Therefore, it would be necessary to make modification, not taught in the prior 
art, in order to combine 3GPP 1997 and 3GPP 1999 in the manner suggested and to 
conclude claim 1 . 
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Therefore, the 3GPP 1999 does not teach or suggest all the features in the 
amended claim 1 as a whole. 

Further, the 3GPP 1999 does not teach or suggest how to use the cause values. 
The Examiner opines that according to 3GPP 1999 and 3GPP 1997, one skilled in the art 
can use replace general response such as "no resource available" with more descriptive 
response message such as "All dynamic PDP addresses are occupied." Applicant 
disagrees with this because one skilled in the art may not always replace general response 
such as "no resource available" with more descriptive response message such as "All 
dynamic PDP addresses are occupied." The reasons are that: if just according to the 
definitions of 3GPP 1999, in practical applications, Applicant found that each equipment 
provider has its own understanding of the protocols, and in case of an implementation of 
the GTPvl version, it is in line with the specifications either to use the new Cause values 
"All dynamic PDP addresses are occupied" and "No memory is available" or to use the 
value "No resources available" as in the GTPvO version. In other words, during practical 
applications, different equipment providers always use different cause values. However, 
because the newly added Cause values in the GTPvl version can not be supported by 
GSN nodes use the GTPvO version, potential trouble of incompatibility exists. For 
example, if the processing result is that the GSN fails to create a PDP context because no 
free dynamic PDP address is available, the cause value may be filled with "All dynamic 
PDP addresses are occupied" or "No resource available" according to different equipment 
providers' understanding of the protocols. If the cause value is filled with "All dynamic 
PDP addresses are occupied" without considering the version number of the request, the 
sender can not understand this cause value if the sender just use the GTPvO. If the cause 
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value is filled with "No resource available" without considering the version number of 
the request, the sender can understand this cause value no matter which version the sender 
uses, however, the definition of "All dynamic PDP addresses are occupied" would be 
wasted if the sender uses the GTPvl. However, the 3GPP 1999 does not consider the 
above problems, nor can it teach or suggest a solution to solve the above problems. 
Applicant respectfully submits that no prior art teaches or suggests how to use the cause 
values as recited in the amended claims 1, i.e., the features of 2D, 2E and 2F as recited in 
the amended claim 1 . 

Specifically, 2D) recites: if the processing result is that the GSN fails to create a 
PDP context because no free dynamic PDP address is available, reading the Create PDP 
Context Request message and checking the version number of the message according to a 
message header thereof, if it is the GTPvl version, the Cause value is set as "All dynamic 
PDP addresses are occupied"; otherwise, it is the GTPvO version, and the Cause value is 
set as "No resources available". 2E) recites: if the processing result is that the GSN fails 
to create a PDP context because there is no enough memory available, reading the Create 
PDP Context Request message and checking the version number of the message 
according to the message header thereof, if it is the GTPvl version, the Cause value is set 
as "No memory is available"; otherwise, it is the GTPvO version, and the Cause value is 
set as "No resources available". 2F recites: if the processing result is that the GSN fails to 
create a PDP context due to lack of resources other than the above, setting the Cause 
value as no resources are available without checking the version number of the created 
PDP context request message . In view of the above different features, the amended claim 
1 recites two cases to use the cause values of "All dynamic PDP addresses are occupied" 



HW 0311064US 



Page 8 of 11 



and "No memory is available" respectively, i.e., the two cases of "the processing result is 
that the GSN fails to create a PDP context because no free dynamic PDP address is 
available and the version number is GTPvl" and "the GSN fails to create a PDP context 
because there is no enough memory available and the version number is GTPvl". Further, 
the Cause value is set as no resources are available without checking the version number 
of the created PDP context request message in the case that the processing result is that 
the GSN fails to create a PDP context due to lack of resources other than the above two 
cases. The above steps of D, E and F can ensure smooth communications between the 
two versions. 

In addition, 3GPP 1999 does not disclose when "checking the version number of 
the message according to a message header" is performed as recited in the amended 
claim. Examiner recites that "3GPP 1999 disclosed the version field is an always-present 
field in the header of the message, thus it is read no matter what". Applicant disagrees 
with the Examiner. "An always-present field in the header of the message" only indicate 
the field could be read but not indicate when the field is read. The Examiner has not 
presented a convincing line of reasoning as to why it is read no matter what. While in the 
amended claim 1, it is clearly defined the filed is read in the two cases. 

Further, the performing internal processing and getting a processing result before 
checking the version number and the checking the version number in some cases to 
implement compatibility of different protocol versions can not be obtained from the cited 
documents obviously. Even combined the 3GPP 1999 with the 3GPP 1997, what can be 
conceived by those skilled in the art may be checking the version numbers in all cases 
since the 3GPP 1999 and the 3GPP 1997 describe two versions respectively. However, 
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compared with the cited documents, the amended claim 1 brings much higher efficiency 
that the GSN would not need to check the version number of the message in all cases. 

The Examiner opines that the internal processing should be performed after the 
version number is checked. Applicant disagrees with this. According to the features of the 
amended claim 1, it is obviously that the internal processing is activating the PDP 
context, which can be performed without checking the version number as one skilled in 
the art known. Further, the processing result is whether the GSN fails to create a PDP 
context or not, which is also irrelevant to the version number. Therefore, Applicant 
respectfully submits that the internal processing can be performed without checking the 
version number. 

Therefore, Applicant respectfully submits that claim 1 is patentable in view of 
3GPP 1999 over 3GPP 1997. 

Therefore, it is respectfully that the amended independent claim 1 meets the 
requirements of patentability. 

Dependent claims 2, 5 and 6 are also patentable over the cited documents 
accordingly. 

In conclusion, it is believed that all of the stated grounds of rejection have been 
properly traversed, accommodated, or rendered moot. Applicants therefore respectfully 
requests that the Examiner reconsider and withdraw all presently outstanding rejections. 
It is believed that a full and complete response has been made to the outstanding Office 
Action and the present application is in condition for allowance. Thus, prompt and 
favorable consideration of this amendment is respectfully requested. 
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In view of the above, Applicant respectfully submits that this response complies 
with 37 C.F.R. § 1.116. Applicant further submits that the claims are in condition for 
allowance. No new matter has been added by this amendment. If the Examiner should 
have any questions, please contact Applicant's attorney at the number listed below. The 
Commissioner is hereby authorized to charge any fees that are due, or credit any 
overpayment, to Deposit Account No. 50-1065. 

Respectfully submitted, 



August 17, 2009 /Ira S. Matsil/ 



Date Ira S. Matsil 

Reg. No. 35,272 
Attorney for Applicant 
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17950 Preston Rd., Suite 1000 
Dallas, TX 75252 
Tel: 972-732-1001 
Fax: 972-732-9218 



HW 0311064US 



Page 11 of 11 



